Business Analyst Community & Resources | Modern Analyst

Business Analysis in the Age of AI

Pulkit Singhal — Fri, 01 May 2026 19:24:00 GMT

Business analysis work has become faster and more efficient over the past few years. Requirements are documented more quickly, discussions are summarized sooner, and solution options are produced earlier in the delivery cycle than ever before. Yet many Agile and product teams are discovering an unexpected truth: as delivery accelerates, the importance of human judgment increases rather than diminishes.

The central question facing business analysts today is no longer whether tools and automation belong in analysis work, but where judgment must take precedence. That distinction matters because the most serious failures in delivery rarely come from obvious mistakes. They emerge from reasonable decisions that appear correct at the time and gradually move teams off course.

Where Acceleration Helps and Where It Falls Short

Modern analysis practices are excellent at speeding up work that is inherently mechanical:

Converting discussions into draft requirements
Identifying patterns across large volumes of data
Refining user story language
Summarizing customer or stakeholder feedback

When used well, this removes low‑value effort from the analyst’s workload. When relied upon uncritically, it creates the illusion of progress.

The challenge is not poor quality output. The real risk lies in outputs that are clear, structured, and confident enough to pass surface review, while subtly reinforcing incorrect assumptions. This is where judgment becomes decisive.

Judgment Gap #1: Determining Whether a Requirement Is Worth Building

Clear and complete requirements do not guarantee meaningful outcomes.

In day‑to‑day delivery, analysts encounter familiar patterns:

A requirement addresses a visible symptom rather than the underlying problem
Stakeholders agree on wording but diverge on expected results
A feature meets acceptance criteria yet produces no behavioral change

Experienced analysts pause to ask questions that artifacts alone cannot answer:

What decision or behavior is supposed to change as a result of this work?
If this is delivered perfectly and nothing improves, what are we missing?

Strong analysis is not just about expressing requirements well, but about challenging their intent.

Judgment Gap #2: Interpreting Context That Never Appears in Documentation

Business environments contain layers of context that rarely make it into requirements or datasets:

Organizational dynamics and power structures
Regulatory concerns driving risk‑averse behavior
Legacy failures that shape stakeholder trust
Competing incentives across teams

Analysts recognize these signals not because they are documented, but because they have seen the downstream effects:

Solutions that are functionally correct but poorly adopted
Processes that are bypassed in practice
Reports and dashboards that exist but are ignored

Judgment here is not guesswork. It is pattern recognition developed through exposure to real consequences.

Judgment Gap #3: Recognizing When Clarity Creates False Confidence

Early clarity is often welcomed as momentum. Detailed backlogs, well‑defined flows, and polished models can make teams feel aligned and confident.

Seasoned analysts remain cautious.

They ask whether clarity is reducing uncertainty—or simply hiding it:

Are assumptions being locked in too early?
What would invalidate this design once it is tested?
Are open questions being resolved, or quietly deferred?

Sometimes the most responsible decision is to leave things deliberately unresolved, even when tools and processes encourage premature finalization.

What This Means for Business Analysts

As delivery mechanics become faster, the value of business analysis shifts away from producing artifacts and toward exercising judgment:

Framing the right problems
Interpreting conflicting signals
Evaluating consequences under uncertainty
Challenging assumptions before they harden

These capabilities are not procedural skills. They are developed through experience, reflection, and exposure to real outcomes especially failure.

Closing Thoughts

Modern tools and practices have made business analysis more efficient, but efficiency does not replace responsibility. The most effective analysts are not those who produce the most artifacts in the shortest time. They are the ones who know when clarity is helpful, when it is premature, and when the best contribution is to pause and ask a different question altogether.

That work remains deeply human and central to successful delivery.

When Should an Analyst Suggest Using Queues in Integrations?

Andrii Siryi — Tue, 28 Oct 2025 15:43:00 GMT

One of the most underrated skills for a business or system analyst in integration projects is knowing when to recommend a message queue — tools like RabbitMQ, Kafka, or Azure Service Bus.

Let’s be honest: not every integration needs one. But when it does, queues can save your system from chaos.

What Queues Actually Solve

Message queues are not just “another tech buzzword.”
They handle asynchronous communication — meaning systems don’t have to wait for each other to respond.

Example:
Instead of sending an invoice from System A and waiting for System B to confirm,
System A drops the invoice into a queue.
System B picks it up when it’s ready.

Benefits:

Smooth data flow even if one system is slow or offline
Built-in retry and error handling
Better scalability — handle thousands of messages per second
Natural decoupling between systems (less spaghetti logic)

When Analysts Should Recommend Queues
You don’t need a queue for every integration. But consider it when you see these signs:

High volume of transactions — more than a few thousand per hour.
Unstable or external systems — APIs that sometimes fail or have latency issues.
Different processing speeds — one system sends faster than another can receive.
Business-critical data — where you can’t risk data loss or duplication.
Complex workflows — where multiple consumers (systems) need the same event.

When Not to Use Queues

For real-time user interactions (e.g., “show me the balance now”) — queues add delay.
For simple 1:1 synchronous API calls — direct REST is cleaner and faster.
When the team can’t support monitoring (queues need visibility and alerts).

As an analyst, you don’t have to design Kafka topics or RabbitMQ exchanges.
But you should recognize the moment when a queue turns from “technical detail” into a business enabler — ensuring reliability, scalability, and peace of mind for everyone involved.

For Business/System Analysts who work with ERP integrations.

Andrii Siryi — Tue, 28 Oct 2025 15:42:00 GMT

When designing ERP integrations (for AR/AP document flows), Business/System Analysts often face a range of “gotcha” questions — technical, architectural, and sometimes unexpected.
Here are some of the real-world questions I ask clients during the API and ERP connector discovery phase:

What’s the minimum required ERP version to support all AR/AP endpoints?
Could upgrading the ERP version change the API behavior (fields, formats)?
Are there any heavy or slow API methods under load? Recommended workarounds?
Does the ERP provider charge for API calls, or is usage unlimited?
Can we get a list of possible API error codes?
Any record count limits per request? (e.g., max 1000 records in GET)
What type of authentication is used — Basic Auth, OAuth2, or token-based?
What’s the average response time of the API?
Are there any debug/logging tools if something goes wrong with the call?
Any breaking changes in recent patches that could affect us?
Does the API support batch insert/update or only record-by-record?
In what format are dates returned? Full datetime or date-only?
How are balances returned (positive/negative for credit memos)?
Can documents be posted without updating the "last modified" date?
Can an account include multiple subsidiaries? How to filter by them in the API?
Are any API methods planned for deprecation? What will replace them?
Are some API endpoints available only with paid ERP modules or add-ons?
Are some fields or features hidden unless specific ERP configuration settings are enabled?
Does the ERP API return full relational data (e.g., linked documents, GL splits), or do we need extra queries?
How can we detect deleted records if the API doesn’t expose a deleted flag or status?

These questions aren't just technical — they help avoid costly mistakes, failed syncs, or misunderstood logic.

Field Mapping vs. Canonical Data Model — Which One Wins in Integrations?

Andrii Siryi — Tue, 28 Oct 2025 15:39:00 GMT

When building integrations between systems, one of the first architectural choices you’ll face is how to align data between them.
Two main approaches dominate this conversation: direct field mapping and the canonical data model.
Let’s break them down.

Field Mapping: Simple but Fragile

Field mapping means you connect each field from System A directly to a matching field in System B.
It’s fast to implement and easy to visualize:

Example:
“CustomerName” → “ClientFullName”
“InvoiceDate” → “BillingDate”

Pros:

Quick setup for simple integrations
Easier to debug and understand
Great for 1-to-1 integrations

Cons:

Every new system adds complexity — you end up maintaining dozens of mappings
Any field name or format change breaks the flow
Hard to scale beyond a few connections

This approach is fine for small, stable environments — like syncing data between CRM and ERP once a day.

Canonical Data Model: Structured and Scalable

A canonical model introduces a shared, unified data layer — a kind of “translation dictionary” for your enterprise.
Instead of connecting systems directly, each system maps to the canonical schema.

Example:
System A → Canonical Model → System B
“CustomerName” → “Customer.FullName” → “ClientFullName”

Pros:

Greatly simplifies multi-system integrations
Reduces maintenance costs over time
Makes it easier to add or replace systems

Cons:

Requires more design work upfront
May be overkill for small projects
Needs governance and version control

This approach shines in large ecosystems — where data flows across multiple ERPs, CRMs, or custom apps.

So… Which One to Choose?

If you’re connecting two systems and don’t expect frequent schema changes — use field mapping.
But if your integration landscape is growing and you want to reduce long-term pain — invest in a canonical model early.

Think of field mapping as a shortcut, and the canonical model as a foundation.

YAML-Based Story Mapping

Andrii Siryi — Tue, 28 Oct 2025 15:37:00 GMT

System Analysts who work with integration processes should formulate user stories in a way that diverges from the traditional structure. This is primarily due to the need for a more technical and structured description, which allows for the inclusion of integration-specific details.

The user story might need to specify exactly what kind of data should be retrieved via an API, from which system, using what HTTP method, and so on.
Additionally, such user stories can incorporate validation requirements.
For instance, before sending the data to an external system through an API, certain transformations or formatting might be required.

As a result, the structure of a user story in this context tends to differ significantly.

Here’s an example of how a story might look:

story_map:
epic: "Invoice Integration"

user_stories:

id: US001
title: "Obtain AR invoice"
as_a: "Application X"
i_want: "obtain AR invoices from ERP {{X}} via API"
so_that: "I can handle this invoice and send to the client"
source_system: "ERP {{X}}"
target_system: "Application X"
direction: "pull"
api_call:
method: "GET"
endpoint: "/api/invoices"
auth_required: true
id: US002
title: "Validate data"
as_a: "Application X"
i_want: "validate the fields of the received invoice"
so_that: "I don't sync the invoice with errors"
validation:
invoice_number: "required"
invoice_id: "required"
invoice_total_amount: "should be > 0"
invoice_status: "should be 'posted'"
id: US003
title: "Push invoice payment"
as_a: "Application X"
i_want: "push the invoice payment created in Application X to the ERP"
so_that: "the payment is approved in the ERP and synchronized back"
source_system: "Application X"
target_system: "ERP {{X}}"
direction: "push"
api_call:
method: "POST"
endpoint: "/api/payments"
auth_required: true

7 Essential Skills Every Modern Business Analyst Must Master in 2025

stivo — Wed, 21 May 2025 17:00:00 GMT

Introduction

In today’s fast-paced digital landscape, the role of the business analyst is evolving faster than ever. No longer just requirement gatherers, modern BAs are strategic partners who bridge business needs with technology solutions. Whether you're a seasoned analyst or just starting your journey, mastering the right skill set is key to staying relevant and effective.

1. Critical Thinking and Problem Solving

Business analysts must interpret complex business problems and identify the best solutions. Critical thinking allows you to question assumptions, analyze root causes, and weigh options with a clear, logical approach.

2. Data Literacy and Analytics

With organizations increasingly relying on data-driven decisions, a BA needs to be comfortable interpreting data sets, visualizing insights, and collaborating with data teams. Tools like Excel, Power BI, and SQL are becoming core skills.

3. Requirements Engineering

Clear, concise, and testable requirements are at the heart of any successful project. Master techniques like user stories, use cases, and functional specs, and adapt to Agile environments where continuous refinement is the norm.

4. Process Modeling and Analysis

Understanding business processes and how to optimize them is a cornerstone skill. Learn to use BPMN (Business Process Model and Notation), flowcharts, and value stream mapping to visualize and improve processes.

5. Communication and Stakeholder Management

From eliciting requirements to presenting solutions, communication is everything. Being able to manage conflicting interests, run productive workshops, and communicate technical topics to non-technical stakeholders is essential.

6. Understanding of Emerging Technologies

Staying ahead means having a basic grasp of technologies like AI, automation (RPA), and cloud platforms. You don’t need to be a developer, but understanding their business impact is crucial.

7. Adaptability and Continuous Learning

The tools and methodologies of today might be obsolete tomorrow. Top analysts constantly learn, adapt, and evolve—whether through certifications (like CBAP or PMI-PBA), online courses, or community engagement.

Conclusion

The modern business analyst is a hybrid professional—part strategist, part technologist, and part communicator. By mastering these essential skills, you’ll not only remain relevant but also become a key player in shaping your organization’s future.

Top 10 Mistakes in Requirements Elicitation

Trividh Patel, CBAP — Tue, 27 Apr 2021 05:47:00 GMT

Elicitation involves bringing out or drawing out information. Elicitation is a key task in business analysis as without proper elicitation the requirements for the solution to the business needs cannot be identified.

1. Not understanding underlying business need

Organization’s business environment keeps changing with respect to Customers, Marketplace, Technology and Marketing function. It is these changes in business environment that leads to identification of business needs at the strategic level in terms of problem or opportunity faced by the organization.

Defining business needs is the most important step in business analysis. Without understanding and defining underlying business needs, it would not be possible to identify all affected stakeholders and elicit appropriate requirements.

2. Not identifying all affected stakeholders

It is important to identify all the stakeholders affected by the given business need. If any stakeholder is identified late (or worst not at all!) may lead to incomplete set of requirements and could require a revision to requirements increasing project cost and time.

3. Treating elicitation as a phase

I have found many Business Analysts consider elicitation as a phase after planning (and before requirements analysis). But this is not true. If you think little more deeply, information gets elicited whenever we interact with stakeholders such as sponsor, domain subject matter experts (SMEs), implementation SMEs, users etc.

Elicitation is performed to understand the current state and elicit business requirements. Business requirements are used when eliciting stakeholder, solution and transition requirements. During requirements analysis, we may identify gaps which would require further elicitation. Information is also elicited from the stakeholders about solution performance after implementation of a new solution.

So elicitation is performed on an ongoing basis as long as business analysis work is performed.

4. Not asking probing questions to elicit requirements

Many novice Business Analysts assume stakeholders can proactively provide all the detailed information required for the business analysis work. Such a passive approach can be called requirement gathering but not an elicitation. Such an approach can only lead to identification of shallow requirements.

It is the job of the Business Analyst to extract or draw out the detailed requirements from the minds of the stakeholders. Business Analyst need to ask probing questions to elicit detailed requirements.

5. Not setting stakeholder’s expectations

In your career as a Business Analyst, at times you would find some stakeholder who would state their wants (whims and wishes!) as if they are their needs and expect them to be in the solution. You may find their expectations not only difficult but impossible. If you capture their wants as requirements it would be difficult later on to deliver to their expectations.

With your interpersonal and negotiation skills you need to communicate and set the right expectations.

6. Not using combination of complementary elicitation techniques

I have seen many Business Analysis teams often rely only on one technique such as interviews for elicitation. While interviews is the most effective elicitation technique but its effectiveness depends on the skills of the Business Analyst such as business domain knowledge and ability to ask probing questions.

So, apart from interviews, a Business Analyst should have knowledge of other commonly used fundamental requirements elicitation techniques such as Document Analysis, Observation and Prototyping. While a senior Business Analyst should have knowledge of advanced elicitation techniques such as Brainstorming, Focus Groups, Requirements Workshops and Surveys.

A Business Analyst should be able to understand the given situation and use combination of complementary elicitation techniques.

7. Not eliciting assumptions and constraints

Requirements are often stated (knowingly or unknowingly) based on certain assumptions which are believed to be true at that time. Requirements get impacted if those assumptions are later found to be false.

Constraints are limitations or restrictions (such as regulatory restrictions, budgetary restrictions, time restrictions etc) that restrict potential solutions to requirements. Identified potential solutions may change if there are any changes in the constraints.

If underlying assumptions and constraints are not captured for requirements, it would be difficult to assess impact on requirements if certain assumptions are later found to be false and/ or on potential solutions if constraints are changed.

8. No plan to elicit requirement iteratively

In order to elicit requirements, a Business Analyst contacts a stakeholder and requests their time. Many Business Analysts do not plan to elicit requirements iteratively and assume that stakeholders will provide all the information required for the business analysis work.

However, most of times, stakeholders are not aware why they are being contacted. After their initial meetings, stakeholder will have some idea what is expected out of him/ her. In the subsequent meetings, stakeholder is likely to give bit more detailed information. So, in order to elicit detailed information, Business Analyst needs to plan to elicit requirement iteratively.

9. Not confirming the elicited information

Work of elicitation is not over once Business Analyst is done talking to stakeholders. Business Analyst has to organize the elicited information and send it to the stakeholders for review. The purpose is to check if discussion has been properly documented and confirm the elicited information.

10. Not collaborating with stakeholders to have common understanding of requirements

When the elicited requirements are shared with stakeholders, there can be difference of opinions and conflicts between stakeholders. A Business Analyst has to collaborate, mediate and resolve conflict between stakeholders to reach a common understanding of requirements. Business Analyst should identify the stakeholder’s problems and help to identify solutions to satisfy those problems.

About Author - Trividh Patel, CBAP

Trividh Patel has about 20 years of experience in Business Analysis and Consulting in IT services industry.

Currently, he is working as Facilitator and Mentor - Business Analysis providing self-paced online courses in Business Analysis. Previously, he has worked for leading IT Services companies as Business Architect, Lead/ Sr. Business Analyst, and as IT Project Manager. He has executed several business analysis projects for reputed organizations from USA, UK, Europe, Middle East, Japan and India. He has good track record of leading team of Business Analysts to deliver business analysis projects.

Trividh Patel has done MBA in Systems and Bachelor of Engineering from University of Mumbai (India) and is Certified Business Analysis Professional (CBAP) by International Institute of Business Analysis (IIBA), Canada since March 2012. He is also Certified Six Sigma Black Belt.

For Consulting, Coaching or Guidance on IIBA Certification (or just to connect!), Trividh Patel can be reached on LinkedIn: http://www.linkedin.com/in/trividhpatel-cbap

Requirements in Context Part 1 - Just Know It!

Dan Tasker — Mon, 22 Oct 2018 20:23:00 GMT

I have long been a believer in the saying “Context is everything.” As a business analyst dealing with business users, understanding the context of the topic of discussion is essential. In thinking about what constitutes quality requirements it occurred to me that there are a number of additional contexts that play a role. Examples include the organizational maturity level (from Informal through to Optimized) and delivery context (green fields through to package acquisition).

This is the first in a series of articles about business requirements. My primary objective is to help business analysts improve their elicitation and documentation of requirements. With an increased awareness of multiple contexts I believe that the quality of the requirements documented can be improved, and subsequently lead to the better design, development and implementation of business systems.

Mark Twain is credited with saying, “Everyone talks about the weather, but nobody does anything about it.” The equivalent saying in the IT context would be, “Everyone agrees that good requirements are essential, but nobody does anything about them.”A perfect illustration of this is the classic IT cartoon “The Swings”:

What is not funny about this cartoon is that the situation it depicts is as true about business systems delivered today as it was when the above version was published. Over 40 years of struggling, and most often failing to meet user expectations, in spite of unimaginable improvements in technology.

I have no illusions that what I intend to present will magically make it all better. But these articles are at least my attempt to do something about it. If you are reading this it means you are interested in improving your BA skills. Hopefully learning about the impact of different contexts on requirements will lead to that.

The Business Information System Context

I find it virtually impossible to take off my business analyst hat. Any time a family member or friend mentions that they want something – a new car, an electrical appliance, I immediately go into ‘requirements mode.’ I start asking questions intended to help them focus on their thinking in order to lead to making the best choice. It occurred to me that it as I begin to present the various contexts related to requirements that I should set the context for this series of articles. The context of requirements that I intend to focus on is business information systems. And while a complete information system includes a hardware and a network aspect, the requirement contexts that will be discussed will not include these technical aspects. The requirements contexts will focus on business analysts interacting with business users to deliver the functional and information components of a system.

Please note that when I use the term ‘system’, from a requirements perspective that doesn’t mean that every requirement will result in a computer-based solution. Having gathered requirements a subsequent exercise is to determine which of them will be given automated support and which will be left as manual processes.

Functional and Information Components

The earliest “computers” were primarily electronic calculators. They allowed complex formulas to be broken down into individual computational steps. Having expressed these steps in a language the computer could understand the resulting instruction set was ready to receive the data to be manipulated. The end product was a set of calculated results.

When businesses began using computers their objective was to maintain data about their business. Computational requirements were minimal. Simple things like adding or subtracting deposits and withdrawal amounts from a customer’s account balance. The original computerized business systems all performed their functions by reading in batches of data, operating on each record as it went through the system, and producing individual results before the next record was processed.

With the advent of database management systems and access in ‘real time’ to computer applications, more and more business processes could be supported by computers. Today virtually every office worker has a computer on their desk. And thanks to wireless networks and portable devices workers (and customers) outside of the office have access to the information they need when they need it.

With the focus of business information systems being the support of functions that capture and utilise data I offer a variation on the Nike slogan “Just Do It”. The objective of the business information systems we gather and document requirements for should be “Just Know It.”

Functional Context / High-level Requirements

Having established the context for these articles to be business information systems, the journey itself will begin in the next article. In it I will present a technique I have used for many years to help establish the functional context for a requirements gathering effort. The more common term for this functional context is “Project Scope.”

I will also discuss the possibility of combining the scoping exercise with the producing of high-level requirements. The result of doing this reduces that requirements task down to hours rather than days (or weeks). This will be the first of several demonstrations of the strength of applying the thinking that “Context is everything.”

Next article: Requirements In Context Part 2 - The Functional View From 10,000 Feet

Are You Being a Design Illusionist?

Paul Crosby — Wed, 07 Sep 2016 14:31:00 GMT

As business analysts, we are often in the fray of designing. Whether it’s a user interface, report or data fed from one system to another; business analysts create interfaces with human beings and systems. Our design choices impact users and other systems in a very real way. This power can go unnoticed even in our own minds.

Have business analysts become illusionists and pickpockets? Both these skill sets require some of the same sleights of hand. The illusionist uses the blind spots and limits of human vision to fool us. If you haven’t had an opportunity to watch the show called “Brain Games” – give it a whirl. It does an excellent job of explaining how an illusionist can fool our sight and point of view. For the pickpocket, it’s the distraction of a conversation, a tap, or a bump to set your mind off in the opposite direction of where you should be focusing while a sleight of hand takes your wallet.

Are we as business analysts playing a role of illusionist and pickpocket when designing our interfaces? Let’s look at interfaces (such as screens and reports) in a broader sense. An interface in my mind is the presentation or “stage” an illusionist would use.

We all believe we have choices and freedom. Everyone in the western world most firmly believes they have great freedom of choice in being able to do whatever is desirable, affordable and of course legal. You can go just anywhere and do just about anything. But when confronted with a system, website or application with a menu of choices, we fail to see how we are hijacked.

We rarely ask the questions:

(1) What is NOT in the interface? Or why are these my only choices?

(2) What is the purpose or goal of this interface? What is it used for?

(3) Why are these options higher or lower on the interface? More visible or less visible as other choices?

(4) Are these choice empowering me or just distracting me from doing what I need to accomplish?

If you have every used a search engine like Google or an application like Yelp, you get a sense choices are made for you and only certain things are being presented for your attention. I have been told the nearest restaurant or gas station is several miles away – all the while standing right in front of one! I usually chalk it up to “well they must not have gotten into the database yet” but now I’m leaning more to thinking I’m being fooled by the choices I’m presented.

Back in the ancient days at the dawn of computerized civilization – something like 40 years ago for you youngsters – computers were called mainframes. Mammoth monsters that would manage large amounts of data, electricity and generate a lot of heat. They required a forklift to move and had to be water cooled.

In those ancient days of computer myths and data Gods, there was but the humble green screen. To get to all the crap stored in that giant mainframe required you to issue the magic commands. By locating the secret words in the sacred text called “Command Line Reference,” you could instruct the mainframe beast to perform feats of great wonder. In other words, there was a giant three-ring binder with all these commands listed in alphabetical order that you were required to memorize and type correctly. The mainframe didn’t tolerate spelling mistakes, and there was no such thing as auto correct. No Google-like “Is this what you mean?” ever appeared on the screen. Even the help key which was supposed to provide assistance rarely did. This was the world of complete freedom from “the menu”. All the commands were in the book and available and granted they didn’t cover everything you wanted to do, but they did cover a lot of stuff you needed to perform. Yes, you had to memorize a boat load of command line syntax because the mysterious book appeared and disappeared as it desired, but you never felt limited rather you just felt a need to search for the right command.

Enter the age of the personal computer. For simplicity, the command line went away. The mouse was born. There was nothing more entertaining than watching grown men in a room holding the mouse with both hands tightly but gently trying desperately to get that arrow moving in the right direction on the screen. “This mouse thing will never catch on” they grumbled. Suddenly the command line was gone, and menus or buttons presented to us. These were your options. Your only available commands. It didn’t take long before I missed my giant 3-ring binder of commands that gave me all the power.

Over time we became to believe that only the commands we could see were the ones of importance. We would become less and less frustrated at not seeing the things we needed. We are restrained by choices of actions presented. Our perception came to be that if it wasn't presented, it wasn't available.

So let’s take this into the modern smartphone age. The other night friends and I were out at a restaurant having a great conversation. The restaurant was closing because it wasn’t that busy and the owner wanted to call it a night. We asked each other the question “let’s continue this conversation – where should we go?”. We all pulled out our smartphones pulling up Google, Yelp, and the other thousand apps on our smartphones looking for a place that was open late. This searching went on for 15-minutes or so. Now I can be a bit impatient with technology and frankly don’t always find it of much help in situations like these. I quit my search letting the others wade their way through the digital data flowing around with smartphones. Then I looked up.

A beautiful park lay right before our eyes across the street, and we didn’t even see it. We believed our only options to find some place were those our smartphones provided. Did those applications tell us about the park? Not one. How about that food truck with the fabulous desserts? Nope. Not a single one. Our illusion of having choices was broken. Sure we got a lot of options, but it was all about the pictures of the menu or comments from other people that distracted us from answering the exact question “Where should we go to keep talking?”. The menu or interface design didn’t answer our actual question at all. It created the illusion of choice by presenting a small subset of options. All said and done the park was bug-free which is a miracle in Minnesota some evenings. Dessert and conversation continued for hours in the street lamp lit park.

As business analysts or designers, it is easy just to limit user choices to a few as possible to send them down a well-defined and perfectly groomed path. But does that answer their question? How many times have you wanted to say “Siri – lead the way to a great evening with my friends!”. The response from Siri is, “I’m sorry I don’t’ understand what you are asking”.

There are a thousand paths to getting or achieving something. No matter how hard you try to make it simple, it just winds up being even more complicated. Or worse the real thing you need is hidden somewhere because someone felt it wasn’t’ important enough to warrant a button. Some of the best interfaces look very simple on the front end and have a rich set of commands just slightly inside of the interface. As a business analyst and designer, we need to give our users or community a rich experience with our application. Are we the illusionist – forcing users down only one path? Our accounting system has several ways in which to generate an invoice. From a customer contact screen, main menu, sidebar and I’m sure more options remain hidden in the accounting interface. As I watched the finance, customer service, and sales people utilize the user interface with the simple task of generating an invoice, I noticed something important. Not everyone went about taking the same path.

Sales people always went to look at the customer inquiry screen first before generating an invoice. Individuals and their contact information were more important to them, and they would update it before moving on to creating an invoice. Customer service created invoices from the order screens as they were more focused on shipping products. Finance folks just clicked on the main menu option.

Know your users. They each have a story and a way of performing tasks that make sense to them. Think about their “persona” and what they need to accomplish. There is no single path to creating an invoice. Develop a list of capabilities and make sure they are not “hidden” from view. If it all doesn’t fit on a screen, find ways to expand the options for display when requested. Don’t fear including two buttons “Create Invoice” and “Add Invoice” which go to the same screen if it makes more sense to a broader audience of users. It is more about clarity for your users then consistency in terms.

What has a dinner in the park taught me? Smartphones are not as smart as we think they are. Everyone thinks they have choices, but don’t always see the most obvious choice because the choice is not presented in a way the user would understand. Question the choices presented and determine if they are the only choices.

Yes, I still miss my green screen terminal. CMD-1 key forever will mean “useless” help, and a blinking green bar on a black screen will always be a symbol of the endless possibilities to mistype ridiculously long string of text that doesn't make sense to anyone. And that huge 3-ring binder filled with commands-a-plenty works damn good propping the door open.

For more good stuff on business analysis and leadership, check out the blog at Bob the BA.

The most important question for a Business Analyst

Praveen Udupa — Sun, 01 May 2016 14:57:00 GMT

Years ago, I was consulting as a Principal Business Analyst for the second largest company in the world in the money transfer business. One fine morning, I was engrossed in my work when my business stakeholder, (let's call him Tom) arrived at my desk.

Tom: Praveen, I have a change request for you. Well, this is a new business requirement.

Me: Oh...a new business requirement! Okay. Sure..let's hear it.

Tom: You know the search screen that we have (see below). I want to change it.

Me: Okay...

Tom: Essentially, I want you to remove all the search criteria fields, and replace them with just two fields...one, a drop down and the other a text field. The drop down will have the same values as the current search criteria. The Agent (i.e. the User) should first select the search criterion from the drop down, and then enter the search value in the text field.

Me: So, the new screen should look like this, ha?

Tom: Exactly!

Now, here is a question for you. Pause reading this article for a minute and ponder over what you would do at this point if you were me. Here are some options:

Update the Search Transaction use case to reflect the change and pass it over to the design team for implementation
Ask Tom to meet the PM and follow the change control process
This seems like such a simple change...there is no change to the actual search function, just some UI modification...so circumvent the change control process and just get it done
Perform a detailed impact analysis and figure out all other functionality that might be impacted because of this change.
None of the above

What would you do? Which option would you opt for?

Sounds like option 4 would be the most logical path to take.

However, if you chose option 5, you would be right. I didn't choose any of options 1 thru 4 either.

What I did was to ask the most important question that a BA must ask -WHY.

Me: Tom, this is a simple change no doubt. If you could humor me for a couple of minutes, I would really like to know why you need this change? What is happening in the business that triggered you to bring this change request?

Tom: Here is the issue Praveen. You see, when a customer intends to make a money transfer transaction, she first logs on to our website. She then creates a Send Transaction where she enters all the details, i.e. the sender details, the receiver details, the amount of money to be transferred, etc. Once she enters all these details, she saves the transaction.

Me: Okay...got it!

Tom: Then, she takes the actual cash and heads to one of our Agent location. The Agent has access to a money transfer terminal. The Agent asks for her name to pull up the saved transaction on his terminal. The customer states her first name. Now the Agent types in her name in the Last Name field. The transaction is not found. The Agent asks her name again, makes a mistake...and can't find the transaction. The customer is irritated, and she goes out straight to our competitor.

Me: Oh vow!

Tom: That is why I want this change. I want to make sure that the Agent actually asks the customer whether she is stating is her first name, last name or something else. That is why the drop down field. I want to make sure that the Agent is able to pull up the transaction in the first attempt.

Now, my dear reader...think about this real business problem and then look at the "business requirement" that Tom has brought to me. What can you observe?

Did you get it? Exactly...you got it!

One, Tom has actually brought you his perceived solution and has disguised it as a business requirement.

Two, the solution that Tom has brought will definitely NOT solve his business problem. How can having a drop down box eliminate the possibility of making mistakes on the search screen?

Having now understood the real business problem, you can think of several possible solutions:

When the customer saves the transaction, let's create a unique ID. Instead of searching for the transaction using name or other criteria, searching using the unique ID is much more robust
Create an intelligent search function, where there is no need for any search criteria label...enter anything - name, SSN or anything else. Make the search function so robust that it searches all saved transactions and pulls up all transactions closely matching the search value and displays the search results sorted by relevance
Etc...etc...

Think about what would have happened had I not asked that 'WHY' question! I would have ended up implementing what Tom wants, and not what Tom needs. After the new search function is released to production, Tom would have very soon realized that the solution is not working at all and his problem still persists. Who Tom would blame then is anybody's guess.

By the way, in my 15+ year career as a BA, I have noticed several BAs not asking this WHY question. This is why I suspect these BAs become infamous in their team as "just postmen" who add no real value to the project.

I cannot really overemphasize the importance of asking WHY for a BA. A good BA will always understand the true underlying business problem and solve that problem. A good BA will never take any statement from a stakeholder at face value and treat it as a requirement. Remember the 'A' of BA!

P.S. It would be interesting for you to learn that solution #1 above could not be implemented because a competing organization had patented that process! The patent prevented my client from creating any identifier that uniquely identified the transaction. My client therefore had to use one or more pre-existing identifiers to identify the transaction.

Role Of Tacit Knowledge In Business Analysis

CVM — Mon, 29 Feb 2016 02:58:00 GMT

Knowledge can be explicit as well as tacit. Explicit knowledge is something that can be easily documented, studied and transferred from one individual to another. On the other hand, tacit knowledge is knowledge that cannot be easily documented, taught and transferred from one individual to another. It includes the beliefs, attitudes, skills, capabilities, and expertise that an individual uses to perform an activity. Tacit knowledge can be difficult to transfer, as it is deeply rooted within a specific individual and the way that the individual performs specific tasks. The term ‘Tacit knowledge’ was introduced by Michael Polanyi way back in 1958 in his work titled ‘Personal Knowledge. His subsequent work, titled’ The Tacit Dimension’ focused on multi-dimensional aspects of human brain and how we store, process, filter and share knowledge with others. Basically, it boils down to ‘We can know more than we can tell’ theory. As per Michael Polanyi, tacit knowledge cannot be adequately articulated by writing down or verbal communication but can only be revealed through practice in a particular context and transmitted through social networks.

Most of the business analysis work focuses on ‘Eliciting, analyzing, documenting, verifying and validating’ the requirements emanating from the explicit knowledge base. The lack of understanding of the tacit knowledge and failure in unearthing this knowledge base is where majority of projects fail. Because your customer’s didn’t tell you (or rather they couldn’t express their requirements) and because you never knew they ever existed somewhere in their minds, the final product did not meet your customer’s expectation. This is just one scenario. The same holds true when a business analyst captures the requirements in some artifact (BRD, FRD, Use Case, User Stories etc). There is a great deal of tacit knowledge, which never gets on to those documents. It remains within the business analysts tacit knowledge base. The end result is the same i.e. final product not meeting the customer’s expectations. I believe it is imperative for a business analyst to take the lead and ensure that the requirements, hidden in customer’s tacit knowledge base, also get’s into the final product.

The below techniques will help business analyst to elicit the stakeholders requirements emanating from the tacit knowledge base and thereby delivering a product that’s build on both, explicit as well as tacit knowledge base:

(1) Close Collaboration: Collaboration and communication is the key to elicit requirements from the tacit knowledge base. Work as closely as possible with your stakeholders (Customers, SMEs, Solution Architects, Developers, Testers etc). This way a business analyst gets an opportunity to ask scenario-based questions, which might have never explored. Working in a close-knit working environment allows a much fluid communication channel across the entire team and assists team members to synthesize real-world scenarios much more dynamically.

(2) Observation: Observation is used to elicit information by viewing and understanding activities and their context. It is another powerful technique wherein a business analyst can simply observe the process participant how he/she is doing it in a particular way, what are the alternate paths, what are the triggers for taking the alternate paths, possible set of business rules hidden behind those decisions and many other ‘What-If’ scenarios.

(3) Task Analysis: This technique emerged from ‘Applied Behavior Analysis’ field. Task analysis is the analysis of how a task is accomplished, including a detailed description of both manual and mental activities, task and element durations, task frequency, task allocation, task complexity, environmental conditions, necessary clothing and equipment, and any other unique factors involved in or required for one or more people to perform a given task.

(4) Probing Interviews: Probing technique is a skillful way to understand the logic, fully understand the response, or to clear air when a response is ambiguous. There are some tried and tested analysis techniques like ‘Five Whys’, ‘Fish-Bone’ one can use for getting into the roots. The key element here is to ask the right set of questions, which aims at extracting requirements from the customers tacit knowledge base.

(5) Role Playing: Role playing refers to actually replacing a real world actor with you and actually perform a task (manually, or using an application), participate in a business process, execute an end-to-end process or process set of business artifacts. Undoubtedly the most powerful technique to get a ‘First-Hand’ experience and learn from actually doing tasks than hearing from your customers, SMEs or other stakeholders.

As more and more projects move towards an agile environments, where software is delivered with minimal documentation and in a fast-paced environment, understanding and exploring the customer’s tacit knowledge will play a much important role.

Please feel free to share your thoughts and leave your valuable comments.

Thanks & Regards

Chetan Mehta

You are not the user : 4 tips to elicit better requirements

Eric Provost — Sat, 17 Jan 2015 03:13:00 GMT

I recently had the chance to spend half a day with some customer service representatives (CSR) in one of my organization's call centers, in order to get a better grip on their work and to see how they interact with the multiple systems available to them to better serve our customers.

I didn't answer any customer call (God bless them!), but I sat next to my assigned CSR with my headset and listened to real customer calls while watching him navigating through our systems to answer the customer requests.

At first sight, you may think, "What a boring way to spend a day at work!" After all, as a Business Analyst and as a former System Analyst in this organization, what could I have learned from this experiment that I still didn't know?

Well, I actually learned one key thing: I had absolutely no idea how our systems were really used by our users in real life.

Fact: you are not the user

In most of my projects, I rarely talk to real users to elicit requirements. Sometimes, I work with a department expert or a division project manager who acts as a user representative to elicit requirements. When I'm lucky, I have access to one selected real user for a few workshops. In most cases, I try to figure out by myself the best solution to a problem based on my incomplete knowledge of the business and systems.

The core of the problem here is that it's hard to reach the real users. They have full-time jobs, have responsibilities and daily tasks to achieve, and simply cannot be freed for days to participate in requirements workshops.

The consequence is clear : without users, business processes and systems can't work efficiently. At best, some minor things will be missing. At worst, users will refuse to use the new solution because it makes their life miserable.

Fortunately, there are some things we can do as BAs to prevent this.

4 tips leading to the right requirements

1. Do not use proxy users

The best way to get information about business processes & procedures and understand their current problems is to talk with the real users. You don't want to introduce noise in the conversation by adding layers of people between you and them, like I described above.

By being able to work with multiple users from multiple departments, you will get richer information, especially when it comes to details, exceptions and variations in the same procedure / activity.

2. Ask them how they work

Asking questions is almost as natural as breathing for a business analyst. You need to ask many questions to your users until you can reach a perfect understanding of a requirement.

However, you can't simply walk in a workshop and ask questions as they come to your mind. A good workshop needs preparation, so that you don't waste your users' precious time. This will probably be the subject of a future blog post, but in the meantime, this excellent checklist will help you at being a better interviewer.

All this is usually easier when you face real users (and not their proxies) because of interactions that allow you to clarify this in real time.

3. Watch them work

When you ask people questions, they tend to depict an idealized view of a specific situation (or a dramatic view of a bad one). You can reduce this effect by relying on more than one user, but the best way to prevent this is by actually watching them work.

By watching users perform their day-to-day work in a real context, you will be able to validate a lot of information you got by first asking them. Moreover, you will be able to distinguish the "should-be" way to work (which is often the information users will give you first) from the real way to work. In a context where your users have many systems and tools to deal with, it will also provide you unvaluable and more realistic information about how those systems and tools are used.

Be aware that watching users work can introduce some bias in their activites (phenomenon known as the Hawthorne Effect).

4. Involve them in the new solution definition

Working with users to understand the current business processes will bring you a lot of information. However, one thing that is often forgotten is to keep them involved later in the requirements elicitation process, when you try to define a new solution.

Indeed, most users have a lot to say about what's working well (and probably more about what's not!), and have a lot of ideas about what could be improved to help them in their work.

You don't want to rely only on them to define your new solution, but their input will be useful in the long run, by making the solution more acceptable; it will not only be your solution, it will be their solution. You will have a lot less change management to do this way.

I often tell my students that 80% of my job as a Business Analyst is communication. So get out of your office and go toward your users; your life as a BA will be much easier.

* * * * *

Eric Provost, Senior Business Analyst and Lecturer

This post was initially posted on Eric the Business Analyst.com

You Must Question Requests from the Business

Adrian M. — Wed, 07 Jan 2015 12:52:00 GMT

A while back, I was reading a Computerworld - Singapore article on Business Intelligence and embedded in it was a small, but significant, truth about the business analyst role.

The article points out that a common mistake made by many organizations is to treat the business analyst as a request taker. That is - if the business division asks for a change in the process (or requirements, for that matter) the business analyst is supposed to just do it. In other words, they expect the business analyst to be a "yes man" (or woman).

Many folks tend to forget that the word "analyst" is actually part of the titles of the "Business Analyst" and "Systems Analyst" roles. One of they key responsibilities of the business analyst is to analyze the information received and question that information if it does not make sense.

There can be nothing worse than an organization paying top dollar for qualified business and systems analyst only to treat them as note takers or technical writers.

One of the key values that a business analyst brings to the table is the ability to innovate... the ability to ask "Why?"

The other day - I was reviewing a new set of requirements from the business side and noticed one of them which did not make any business sense.

So I dared to question it...

When I question requests from the business I tend to use a very simple approach:

Why?
Why?
Why?

In this particular case, the answer I got was "Because Mr. X said so!"

What? Because one person said so, it doesn't make it so!

Along with every new requirement and change in business process there must be a justification and clear rationale for the request. If it is not clear that the effort will improve the bottom line - then question it, question it, question it!

As a business analyst you need to make sure that somebody (it doesn’t always have to be you) has analyzed the situation and determined that a change in process or system is needed for one of the following reasons:

it reduced operating costs,
it increases productivity (makes money),
it meets regulatory requirements.

I realize that there are other, more subjective, reasons to make modifications such as increased usability of a product, look and feel requirements, etc. Those types of reasons need to be treated with caution because it is hard to objectively quantify their impact to the bottom line.

What are my motives?

... if you question requirements: What are your motives?

After years and years in this profession - this is something I do without even thinking about it - a matter of habit. But after a little bit of introspection here are some of the reasons why I question business requests:

From a pure business perspective, I want to make sure that the change in process or system improves the bottom line. From a sense of preservation I want the organization I work for to be in business for a long, long time.

Because they hired me to do so... I am being paid for my ability to think and solve problems not for my request taking skills. If that was my goal - I would have become a waiter (no disrespect for waiters intended).

Because deep down in my gut I can't stand designing or asking the developers to implement a change in the system which does not make business sense. Such features are bound to be changed again in the future and are a waist of everybody’s money, time, and effort.

Please note that I am not advocating that you overtly question every single request from the business. If you do that, you'll find your way out the door very quickly.

But you should analyze in your mind every requirement to make sure it makes business sense (at least from your perspective).

Use your better judgment and focus on the requirements with the biggest problems.

If you manage and lead business analysts then you must ensure that you get commitment from upper management on the role, responsibility, and authority your analysts must have. Then turn around and empower your team. Make sure they understand that they are allowed to and must question those business requirements (with tact - of course) which are suspect.

Do you question requirements? When? How?

Adrian

The Popcorn Way and the Business Analyst

Adrian M. — Wed, 03 Dec 2014 12:20:00 GMT

The problem: Do you know when you’re done?

Given a specific project with a reasonably defined charter and clear business goals you, the business analyst, set out to elicit and document the detailed business requirements.

So when do you stop?

Whether you lead a team of business analysts or you do the work yourself, you probably struggled trying to determine when you should be done gathering the requirements?

If you are a perfectionist, or know one, you’ll realize that it is possible to spend unlimited time trying to discover new requirements or to refine existing ones. However, in real life and real projects the customer cannot (and will not) spend unlimited amounts of money to build a system.

At some point you have to draw a line in the sand and say “We’re done… at least for now!” The crux of the matter is to determine when we’re done.

One of the most often quoted heuristics offered to answer this question is the 80/20 rule (or better yet the 20/80 rule). That is, spend the 20% of effort which uncovers 80 % of the requirements.

That’s easier said than done!

How do you know that 20% has gone by or that you have uncovered 80 % of the requirements?

To tell you the truth – I have no clue!

The Solution: The Popcorn Way

With the charter and goals of the project in mind, I estimate (or guesstimate) upfront how long I think the requirements gathering activities should last….

… and then I use The Popcorn Way.

I found the technique on the back of my microwavable popcorn bag.

I goes like this:

Microwave popcorn on high for 2.5 minutes (on 500 Watt microwaves) *
Listen for the distance between pops
When the distance between pops exceeds 2 seconds, turn off microwave.

* Note: the actual popping time may vary.

By now you’re probably thinking that I’m going crazy… and maybe I am… but that’s a topic for another time.

If you translate from Popcornish to English, it goes like this (see basic language lesson in appendix):

Elicit, document, and analyze requirements for {estimated duration} using {available resources}
Pay attention to the information that you’re getting and determine the duration between discovering new requirements or significant changes to existing requirements.
If distance between requirements is less than {the threshold for your situation and project}, then end the requirements gathering activities.

* Note: the actual total duration may vary due the type of project and the characteristics of the analysis team.

The basic thought is that during the requirements elicitation process it comes the time when you, the business analyst, realize that you’re finding less and less requirements even though you may be getting more and more information.

When you come to that realization – it’s time to stop – at least for now.

Putting in into Practice

Once you have mastered The Popcorn Way your gut will guide you.

You will be able to clearly spot the requirements silence.

You may be only part way during your estimated duration yet you’re not getting any new requirements or significant changes to existing requirements.

Stop! You’ve probably over-estimated.

Or, you may find yourself scrambling for the pen and paper (or typing 100 words per minute) trying to capture all the requirements flying at you… In this case, you’re definitely not yet done. Should you find yourself in this predicament after your estimated duration elapsed, you've most likely under-estimated the effort.

The Dangers of not following The Way (the Popcorn Way, that is)

I’ll keep this very simple:

If you stop too early you’ll have un-popped kernels => you've missed critical requirements and, from business analysis perspective, you failed.
If you wait too long you’ll burn the popcorn => you've wasted valuable time and probably made real requirements indistinguishable from the fluff. Again – this is not a desired outcome for a business analyst.

Do you use the popcorn method? Do you know when you’re done?

I would love to hear from you! Happy Popping!

The Appendix: Basic Popcornish Lesson

to Microwave (v.) = to elicit, document, and analyze
popcorn (n.) = requirements
2.5 minutes (n.) = the up-front estimate or guesstimate
microwave (n.) = business analyst or business analysis team
500 watts (n.) = an attribute which measures the caliber of your team
distance between pops (n.) = time elapsed between receiving a new requirement or making a significant change to an existing requirement
2 seconds (n.) = the longest time your situation (you can replace with organization, team, management, etc.) will allow you or your team to stay idle while waiting for a new requirement or a significant change to an existing requirement

Your turn: How do you know when you're done or when you should be done?

Adrian

Dealing with Difficult Stakeholders

sbowling999 — Sun, 27 Jul 2014 20:50:00 GMT

The question will undoubtedly arise during your tenure as a business analyst, ‘How do I manage a difficult stakeholder?’

I once encountered a stakeholder, a very highly respected mathematician, who had developed an application based on a mathematical model of his weather systems. The algorithm was amazing. The application sucked. It was my job to:

1. Ensure his model used enterprise data so it could be shared amongst other applications I was helping develop and,

2. To either refactor and debug his application or port his algorithm to a new User Interface so it was available to a larger user group.

Long story short, he hated me. More accurately maybe he hated the idea of me. So what did I do? I elicited his feedback every step of the way. I made him a full partner in the change experience. But I also put my foot down and let him know the change was going to happen. I recognized that he was heavily invested in the application he had grown from scratch. The larger community wasn’t aware of his accomplishment. So I suggested he demo his application to a larger group of users. He got the opportunity to share his vision with the enterprise. People were amazed at the model and he received his just credit and some back slaps. But during the course of the demo he was also slightly embarrassed because there were technical issues and bugs that were apparent (as I knew they would be) which motivated him to embrace the improvement process.

It also helped to understand what was important to him and his own analysis process. Because he was the logical type I crafted my analysis plan to rely more heavily on statistics and fact based decision making. After showing him the error logs for his tool as compared to other applications for example, we agreed together that reducing the instances of error and downtime needed to be our joint #1 priority before we exposed the application to a larger audience. Because I always kept him informed, treated him as my primary stakeholder and never pulled punches, he began to see me more as his partner who could help him through the change process and bring his model to a much larger audience. For that to happen, he had to let go of complete control and we eventually repackaged his model/algorithm into an entirely new UI consistent with our other enterprise applications. Looking back, the only thing I would have done differently is put my foot down on Day 1 instead of Week 3.

It’s also critically important to find out the concerns of your most difficult stakeholder. In another example, I had a difficult stakeholder group who were code enforcement inspectors. You know the guys who condemn houses? As a group they were refusing to use their 2 year old mobile application. Citizen complaints raged as their investigation backlog grew. When their contractor mistakenly demolished the wrong house, the Mayor’s office finally decided to hire me as a consultant to improve their systems and processes. The workers grumbled and pushed back on requests for changes. I decided to select the least tech savvy, most senior vocal influencer and rode with him for a solid week. Every morning at 6 a.m. we met the crew for coffee at McDonalds. I donned work boots and shadowed him as he walked around in dark condemned houses in the worst part of town. We met the guys for lunch at the 7-11, conversed and I truly began to understand their challenges and why they hated the old application. I also understood that the fear of using the technology was elevated due to a general lack of experience with web technology. At the end of the project this ‘difficult stakeholder’ helped me teach the training course and volunteered to be the ‘go to guy’ for all other inspectors! Listening and putting yourself in the stakeholders shoes really works.

So here are my steps to better stakeholder relationships.

Identify key stakeholders who can throw a wrench into your project’s success. Key stakeholders may be members of the executive or management team. They could just as frequently be informal team leaders or members who influence others. Ensure you are proactively nurturing those relationships.
View them and treat them with the importance a key stakeholder deserves. Nothing turns a stakeholder into hostile mode faster than getting a cold reception and the sense that his opinions are not valued.
Take the time to truly understand their perspective and concerns. Put yourself in their shoes. Not only will you be investing in the relationship but you will likely also learn important information that can help craft your analysis, deployment, training or support plans.
Ensure there are ample opportunities for your stakeholders to provide feedback in a setting that is most comfortable to them. Some people aren’t comfortable sharing in a group setting or JAD session.
Be sure to incorporate their feedback into the overall plans so their concerns are addressed.
Recognize that change doesn’t happen overnight. Employ an appropriate change management strategy.
Create opportunities for your difficult stakeholders to show leadership and excellence. Everyone wants to be recognized for their accomplishments.
Engage them to help win the buy-in of other team members who sit on the fence. Nothing ensures your project’s success like having the team leaders champion the change.

The success of a business analyst depends heavily on the relationships he builds along the way. Pay attention to the key stakeholders and remove this obstacle so you can get on with the business at hand.

BABOK v2 - End-to-end data flow diagram analysis can highlight issues

Alan — Thu, 10 Jul 2014 01:20:00 GMT

As part of preparation to sit the IIBA CBAP exam, I wanted a one page summary of the overall BABOK flow. The first step of creating a summary matrix showing a derived master list of documents (e.g. Inputs + Outputs) versus the process that creates or uses it was interesting, but not entirely helpful.

By using the matrix to create an indicative data flow type diagram, that helped to better understand the overall end-to-end process documented in the BABOK.
Note: Clear stakeholder information was not available so a Business Process type Model was not possible.

The data flow type visualization technique is very useful:
1. It is an additional visual means of communicating complex information for people who struggle with understanding just text.
2. It quickly shows the flow of information between the various processes
3. The data flow diagramming conventions help to highlight issues. E.g. No clear sources or uses of specific deliverables, redundant and reverse flows etc.

This is also timely given the review of the Draft BABOK v3 material that has been requested and that closes on July 11th.

How to convince stakeholders of BA value for the first time?

Lee Grinberg, CBAP, PMP — Fri, 21 Jun 2013 13:46:00 GMT

In my previous posts I outlined how I was able to succeed being the first and only BA at a company and the importance of establishing trust between you and the stakeholders.

So you're the first BA at a company. All are looking at you and thinking what can this person do for me?

Good question. What can you do for them?

Show them how your contribution will make their life easier!

I'll tell you how I handled this challenge. I was brought in to write functional specs based on business requirements. The business requirements were good but not complete. The IT folks were afraid that key use cases were missing.

I took the following steps:

Created a context diagram (first one in the company) to show them what scenarios may be missing
Created use cases from the business requirements
Reviewed both with the SMEs. This uncovered many gaps not covered by business requirements

Once gaps were uncovered, the people writing the business requirments were relieved to know the gaps were identified early in the process and not in a later (embarassing) stage. I made their life easier and this was appreciated.

The next steps were around design:

Wrote a detailed functional spec outlining database and functional changes
Clearly wrote out testing scenarios

So what, you may be thinking. After all, this is what BAs do. True, but remember, I was the first and only one in the company so no one was convinced of the value of a BA.

The result of design was that developers were relieved to know they didn't have to have lengthy conversations with the end users about functionality.

The key concept again is to make their life easier!

Once trust is established, however, you must prove that you can benefit the stakeholders.

What Every Business Analyst Can Learn From Journalism: The Art of Intelligent Questioning

Stephanie Famuyide — Sat, 02 Mar 2013 15:44:00 GMT

"Garbage in, Garbage Out" - To elicit accurate requirements, the business analyst must learn to ask the “right” questions “the right way”. The manner in which questions are delivered and the composition of these questions have a direct impact on the usefulness of the responses we receive.

If your questions are properly and thoughtfully framed, not only will you get the appropriate response, your stakeholders will also go away with a feeling that you indeed understand and empathize with them. They should come out of an interview session feeling “understood” not “interrogated”.

According to Donald Rumsfeld’s infamous (but accurate) quote in 2002 regarding the Iraq war:

“There are known knowns - things we know that we know.

There are known unknowns – things we know that we do not know

And there are also unknown unknowns – the things we don’t know we don’t know.”

The known knowns and known unknowns are easier to manage – by asking confirmatory questions to test the accuracy of existing knowledge and asking direct questions to elicit information on grey areas. How then should Business Analysts handle what they don’t know they don’t know? The answer is pretty straightforward:

By opting for open-ended questions.

Open-ended questions are more appropriate where you have limited knowledge on stakeholder issues or expectations. Questions that start with the 5 Ws and H: who, why, what, where, when and how tend to elicit more thoughtful and insightful responses when compared with those that start with: Would, Should, is, are, do you think, and the like.

For example, instead of asking: Do you open physical files for the different documents you receive? It’s better to ask: "How do you manage the documents you receive?"

Using the 5Ws and H also implies that you want to know what your stakeholders' opinions are and you're not just looking for an opportunity to state your own opinions through a leading question.

From Verbal to Visual: Reviving the Lost Art of Prototyping

Stephanie Famuyide — Sat, 16 Feb 2013 09:49:00 GMT

“Something is happening. We are becoming a visually mediated society. For many, understanding of the world is being accomplished, not through words, but by reading images –

Paul Martin Lester, “Syntactic Theory of Visual Communication

Research has shown that communication with a visual dimension is more effective than communication without. Herome Bruner of New York University revealed that people remember only 10% of what they listen to, only 20% of words they read and about 80% of what they see and put into practice.

Though visual communication is deemed more powerful than verbal communication, a combination of the two, carefully and intelligently blended can be extremely powerful.

Look around you. Visual communication is everywhere - from presentations at work to directions on the street. Today’s generation now lean towards a different mode of learning; there's a pervasive preference for videos, pictures, flashcards and presentations. Communication is now achieved visually more than ever.

Beyond the ability to deliver compelling presentations, the perfected art of visual communication can be extremely useful when dealing with stakeholders. Understanding a 10-page business requirements document can be made easier if the business analyst employs the use of mock-ups/prototypes and process diagrams.

Edward R. Tufte has emphasized that “To envision information—and what bright and splendid visions can result—is to work at the intersection of image, word, number, art.”

Employ the use of charts, diagrams, tables and colours wherever you can to deliver a powerful combination of the visual and the verbal.

Next time you're churning out that business requirements document, consider using pictures instead of a thousand words....

Stephanie Famuyide (Stephanie@businessanalystlearnings.com)

http://businessanalystlearnings.com

Follow-up to “So, you’re buying a package? Don’t forget your business requirements…” Don’t over-analyze!

David Wright — Sat, 09 Feb 2013 02:47:00 GMT

For those of you who do define requirements for their software development projects, but are new to buying packages, a cautionary warning; they are not the same thing. Consider the following “the system shall” requirement statements.

1) The system shall determine if a person ordering pizza is a current customer.

2) The system shall determine if a person ordering pizza is a current customer, only if the person is phoning to place an order.

3) The system shall determine if a person ordering pizza by phone is a current customer using the person’s name and phone number.

Each requirement is at a certain level, increasing in detail from (1) to (2), and from (2) to (3).

- Requirement (1) is at high-level, stating that the system shall do something with certain information.

- Requirement (2) is more detailed, stating that the system shall do something with certain information, in a certain situation.

- Requirement (3) is fully detailed, stating that the system shall do something with certain information, in a certain situation, according to certain rules.

Requirement (3) is what you need to provide to designers/developers to use in new software development. However, this not what you need to provide to vendors when you send them an RFP; in fact, this level of detail can be over-kill analysis and can restrict the number of vendors who could meet your needs. By being very specific about rules and restrictions, you may eliminate a vendor who has a different and possibly better approach to meeting the business need, e.g. a better way to determine who is a current customer.

So what level of detail do you need? High level requirements like (1) can be useful at the start of a project, to describe scope and support planning; this level can also be used in a Request for Information (RFI) sent to vendors, just to get an initial view of what the marketplace looks like.

When you get to an RFP, you need more detail to differentiate vendors better, and Requirement (2) is an example of this level, which I call mid-level or standard-level of detail for requirements. At this level, you can see the difference between vendors in meeting your requirements, enough to evaluate their product and decide which one will serve you best.

So I now have two recommendations for organizations looking to buy a package:

- Don’t forget your business requirements…

- … but don’t over-analyze your needs, so you can best evaluate those packages.

The job ain't finished until the paperwork is done!

hildasteyn — Sun, 10 Jun 2012 06:20:00 GMT

I started my career as the administrator in a project management department. The first fact drilled into my head was that “the job ain’t finished until the paperwork is done’. To emphasize this fact, this rule was printed and put up on the wall with a picture of a toilet paper roll. It worked. I know you can see the picture in your head.

Many times I hated the person who invented filing. It must have been one of the most boring duties ever. In those days, every piece of paper had to be punched and the holes had to be reinforced with little round stickers before filing. Dreadful, I tell you, dreadful.

Today, it’s so much easier. Enterprise Content Management (ECM) makes it so much easier to keep all the important documents together. Retrieval has become so much easier with index and search functionalities.

Which brings me to my reason for writing this blog today. With all the modern ECM technology at hand, why on earth are there still organisations that don’t document a single thing? I am once again in that weird place where I have to analyse a business system and there is nothing documented anywhere. Business rules are in different people’s heads and to get them all out is a daunting task. People forget things you know – it’s human. The more I try to understand the current business process, the more I am confused. Every user has a different process in his / her head. Some users do things without knowing why they do it. Other users think it should be done differently, but can’t give a reason why. And then the classic one – the user that can tell you that the current system doesn’t work well, but he cannot give you one indication of what he needs for it to work well.

Oh the joy of being a Business Analyst!

Challenges like this one is rewarding. I know, I have been here before. It’s the greatest feeling of satisfaction when it all starts to finally make sense. The more you work on the new design, the more satisfying it gets. And the day the new system rolls out is like the birth of a new baby in the family. Sheer joy!

But, the job ain’t finished until the paperwork is done. As Business Analysts, we have to leave behind more than just a new system that works. We have to leave behind a fully documented system. We cannot repeat the sins of the past and leave a system behind without the necessary documentation stored somewhere. At least if the next BA comes, there will be something to start working with.

Hilda Steyn
Business Analyst, Pretoria, South Africa
@broomformybrain

Information Systems Users don't know what they want... So, don't ask them what they want...

David Wright — Sun, 07 Aug 2011 03:12:00 GMT

Information Systems Users don't know what they want... So, don't ask them what they want: and definitely don't write some software and then say "how's this look?".

On the other hand, don't have someone spend weeks talking to various people about what they want ( and not get to talk to other people ), write it all down and deliver a document, saying "build this"... and then spend months building "this" and then say "here you go".

But, something must be done; start with a change of focus - Information Systems should not do what users want, Information Systems should do what an organization needs to be successful.Isn't that the same thing?

It should be, but users are people and one person seldom wants what other people want; and people are notorious for wanting one thing now, and something else next month... or even tomorrow.

So change focus - from people to organization, and from wants to needs.

The User Myth

Please keep in mind that the scope of my opinion is Information Systems, mainly the type of systems that people are paid to use, people otherwise known as 'employees'.

A lot of systems and software are not in this scope. For example, what I have written here was first drafted using a notes app on my mobile device; that is a whole different thing, one I always want to explore... But when I go out to work for clients, it is almost always for Information Systems: "we need a new system to process more orders" ... "our loan approval system has to be expanded" ... "the State is changing the rules for UI eligibility" ...

So let's address the User Myth.

First, I am not the first person to note that the only other people who are referred to as "users" are drug addicts, but it seems to be a term we are stuck with. Seriously, when I drive, am I a car user?

Now consider those employees I mentioned up front. When they are hired, they always get trained on the existing systems they need to do their work. Given the multiple-year lifespan of a typical information system, and the usual level of turnover in a department/function of an organization, a lot of people will use a system over time. Very few of this number will have been there for the introduction of the system, and usually none of those people will still be around when the system is retired and replaced with something else.

And yet we are supposed to assume the group of people using a system at it's retirement are automatically the experts who should be asked what they want in a new system? Think about this for a moment or two; that should be all the time you need to conclude "well, no".

That's because users come and go, but systems (seemingly) go on forever.

The current group of employees who are expected to use a new system are indeed important stakeholders and participants in creating that system, but they are not the only ones. (And still, some of them could be gone before the system is finished.)

So change your focus to the needs of the organization; stay tuned for my approach on doing just that.

Requirements Gathering

a.prvz — Wed, 08 Jun 2011 09:49:00 GMT

Requirements gathering is an essential part of any project and project management. Understanding fully what a project will deliver is critical to its success. This may sound like common sense, but surprisingly it's an area that is often given far too little attention.

Many projects start with the barest headline list of requirements, only to find later the customers' needs have not been properly understood.

One-way to avoid this problem is by producing a statement of requirements. This document is a guide to the main requirements of the project. It provides:

A succinct requirement specification for management purposes.
A statement of key objectives - a "cardinal points" specification.
A description of the environment in which the system will work.
Background information and references to other relevant material.
Information on major design constraints.

The contents of the statement of requirements should be stable or change relatively slowly.

Once you have created your statement of requirements, ensure the customer and all other stakeholders sign-up to it and understand that this and only this will be delivered.

Finally, ensure you have cross-referenced the requirements in the statement of requirements with those in the project definition report to ensure there is no mismatch.

10 Rules for Successful Requirements Gathering

To be successful at requirements gathering and to give your project an increased likelihood of success follow these rules:

Don't assume you know what the customer wants, ask.
Involve the users from the start.
Define and agree the scope of the project.
Ensure requirements are specific, realistic and measurable.
Gain clarity if there is any doubt.
Create a clear, concise and thorough requirements document and share it with the customer.
Confirm your understanding of the requirements with the customer (play them back).
Avoid talking technology or solutions until the requirements are fully understood.
Get the requirements agreed with the stakeholders before the project starts.
Create a prototype if necessary to confirm or refine the customers' requirements.

Common Mistakes

Basing a solution on complex or cutting edge technology and then discovering that it cannot easily be rolled out to the 'real world'.
Not prioritising the User Requirements, for example 'must have', 'should have', 'could have' and 'would have,' known as the MoSCoW principle.
Not enough consultation with real users and practitioners.
Solving the 'problem' before you know what it is.
Lacking a clear understanding and making assumptions rather than asking.

Requirements gathering is about creating a clear, concise and agreed set of customer requirements that allow you to provide exactly what they are looking for.

Separating Requirements Elicitation from Business Analysis

David Wright — Thu, 28 Apr 2011 19:12:00 GMT

What do you need the most when eliciting Requirements? Face-time with Subject Matter Experts and their Managers. As a Business Analyst employed in a typical organization, what is the thing you get the least of? Face-time with Subject Matter Experts and their Managers. Who will Subject Matter Experts and Managers make time to see? Outside Consultants.

Such is the way of the world, at least the one I have worked in for 30 years. Full disclosure: for about 20 of those years I was an employee Business Analyst. I am now an outside Consultant working in Requirements Elicitation, Analysis and Documentation. I have spent more direct time with SMEs and Senior Managers in the last five years than I probably got in those 20 years. Why? Because I have usually been brought in to work an important project, and I am a direct cost to the organization.

If you the reader are an employee working on projects, and not limited to Business Analysts, you know this true. Is it fair to you? Not really, but having been on both sides of this situation, I don’t see it changing anytime soon.

So rather than complain about it, how can you make this work for you? (And yes, what I will suggest should mean more work for me, but hear me out…)

Name one good thing about Consultants: they bring a fresh viewpoint, and they should bring better practices to deliver what they have been hired for.

Name one bad thing about Consultants (or least what many people I know do think): they leave when they are done, leaving it up to those involved employees to carry on what they probably started in the first place, and see it through to the end.

So, please read the first paragraph again… It does not mention all the other things Business Analysts do for their organizations. The role varies from place to place, but it usually does involve more than getting those pesky requirements. My own extra-speciality was project initiation, scoping, doing cost-benefit analyses, and a little Project Management on the side when pro PMs were not available. My experience over the years is that it is possible for an employee BA to get Senior Managers and Project Stakeholders in a room long enough to bash out a project charter, with goals and expected benefits; that is when these people are most engaged, up front when the idea is fresh and the expectation of good results is the highest. It is later on when you need some serious time to elicit requirements that the reticence to show up starts.

On the other hand, many BA’s participate in downstream activities, like testing, user documentation and training. I have actually had some vigorous discussions in the past with people who say that you aren’t a really a BA unless you do those things. I don’t happen to agree, but the fact that many BA’s do it, and do it well, is current reality.

So, you can probably see where I am going here. Being a BA can involve you from start to finish, but the key thing that makes all of it work, getting those requirements, is the hardest thing for a BA to get done, and done correctly; and boy, do you hear about it if the requirements turn out to be incomplete or incorrect. What’s a BA to do?

Separate requirements elicitation out from the all the rest of the work, and bring in an expert (which is how the business sees consultants) to nail down that important piece. Using good practices and standard deliverables, 5 to 10 days is all that is needed to get it done for a medium size project. That means those SMEs/Managers in a room, together, for those days in facilitated requirements discovery sessions. You get the requirements you need, and actually get them a lot faster than if you tried to get time with everyone in separate meetings, try to get it all down in one deliverable, get everybody to review it and approve it. I’ve been there, you’ve been there, and it can take 5 to 10 weeks, if not longer.

So yes, I am selling myself, and the people I work with, as a solution; there have been many buyers so far.

The smartest customers have taken it one step farther. Once we have demonstrated success, the next step they take is to adopt our practices and train their own BA’s; and, of course, we help them do that as well. The most common approach is to train a few people to be the new internal consultants, and often that role (such as “requirements facilitator”) lives on as support to BA’s on all projects. All it takes is a few early successes and those hard-to-get business people (the start of this whole discourse) will be more than happy to be part of Requirements Elicitation.

So, divide and conquer, then reunite for long term success. That’s win-win-win for everyone.

RML® Model 4 – Data Dictionary

Seilevel — Thu, 05 Aug 2010 18:09:00 GMT

When creating a data dictionary, it is critical not to design with it. You should not be attempting to create a database nor should you be showing the relationships of data. This will be a detailed description of the data involved in your project. It will also be one of the largest morale draining approval processes you can have for a document. They will be very time consuming an have the potential to have a good deal of churn over the data items they hold.

One of my former projects demanded a great amount of detail be gathered from the existing systems to be implemented in a new outside system. Unfortunately there were several large problems with the way Data Dictionaries were used. One of the two largest problems was that there were upwards of twenty different data dictionaries that were being worked on independently by different functional areas of the project. The other huge issue was that only fields that were visible to the business were being captured.

Having multiple data dictionaries for the same project causes many issues and can lead to delayed development and incomplete requirements. If there are 10 different Data Dictionaries that all call for a field identified as ‘Credit’, how does one figure out if they are all the same field? If they are the same field, which of the different entries has the correct business rules and attributes? If they are not the same field, how will the names be reconciled? If they are different, which one was being referred to in other documentation and models? And what about the one field labeled ‘CustCred’. Was that the same? Were all the business SME’s aware that ‘CustCred’ was included in only one of the data dictionaries?

Failure to engage the Business and IT in creating a Data Dictionary can lead to a plethora of data not being identified and documented. Unfortunately when only the business is involved in creating a Data Dictionary, it tends to only get populated with fields that can be seen, either on the screen or in reports. IT will be able to provide input around these fields. What is not being seen is that when you enter your account number and password, the system is keeping a log of your user id, the date the login attempt occurred, the outcome, and your IP address. Without IT there, you could have just lost 4 of the 6 fields required to login. Additionally, if you have to go back a separate time with the IT group, you will have to bring the Business in even more to make sure that the business name you have recorded is the same as the field IT identified. Just because it says customer name on the screen doesn’t eliminate the possibility that it is actually ‘cust_legal_name’ in the database.

I have found the following fields to be a robust baseline for any data dictionary I create:

-ID – unique ID to keep track of the data fields

-Category – Organizational field that can help group data

-Business Name – Official or most widely recognized name for the data

-Aliases – Abbreviations or alternative names the data could go by

-Data Field – Field used in the database (mostly used on gap projects)

-Description – Short description of the field for context

-Formula – If the field is calculated, include the formula used to come up with the value here

-Business Rules – Any actions or restrictions that must apply to this data

-Data Type – generic data type such as ‘alpha’, ‘numeric’, ‘alphanumeric’, ‘currency’, ‘date’, or ‘time’

- Length – Maximum allowed length of the field

-Owner – Individual or group who currently owns an action item for the field

-Status – Draft/Reviewed/Approved/Removed/etc.

- Notes – Misc notes to be taken about the field such as links or individual’s comments

-Issues – List of unresolved issues or action items with the field

Keep in mind that the Data Dictionary is best in situations where you have an undefined data model or in situation where you are involving new systems. This data model will become less useful when dealing with a smaller or more defined/understood data set or if you are short on time.

Unfortunately this model is also not a visual model. This means that it will be much harder for people consuming it to quickly learn the data being presented and it will also be difficult to quickly interpret the data being presented.

You are almost always going to find this document living as an excel spreadsheet. If you plan on having multiple large groups working on the same project, you should consider having a collaboration tool for this document such as Google Docs or SharePoint lists. Multiple lists being worked on separately can cause massive headaches and prove to be massive time sink when trying to correct and compile. As a best practice, one should never delete data either, but rather mark it as removed or do a strikethrough formatting. This will allow you to know that it was documented but deemed unnecessary instead of forgetting about that one remote field and researching it again to find out you cut it already.

Pro Tip for excel users:

Holding down Alt and pressing Enter (Alt + Enter) while typing in a cell will allow you to return

to the next line within the cell as if it were a word document. This will make it easier to format notes or add multiple aliases/data fields to a single row.

Fun tip- for those who have sympathy for making others do a data dictionary review: bring koosh balls, stress relievers or fun packs of play-doh for your attendees to keep their brains semi-active during the reviews.

by jheep

Want more models? check us out here.

Help your stakeholders review your requirements

Craig Brown — Fri, 13 Feb 2009 10:58:00 GMT

Requirements Gathering Between Business Analysts

Chris — Mon, 03 Dec 2007 01:29:00 GMT

I've come to understand the necessity for stakeholder involvement throughout the Requirements Gathering process. But what if it's another BA who is the stakeholder company's point of contact whom you'll be gathering requirements from instead of the stake holder themselves? Is there an advantage? How do we leverage the strength of our Requirements Engineering knowledge to come up with an appropriate set of requirements for a project?

I've been assigned to my first stint at Business Analysis, doing requirements gathering on a Financial Services company's IT upgrade project. Currently, the interfacing is mainly between myself and their BA. A lot has been said of gathering requirements from stakeholders, but this BA (we'll call her J) is my point contact and perhaps the one I've been assigned to doing most of my discussions with. What's the best way to gather requirements through another BA? I've heard it said that it is possibly more advantageous to liaison between BAs since we all speak a similar language of Requirements Engineering. But does this replace the need for stakeholder involvement?

Practically, what are the best questions to ask the stakeholder company's liason BA in the spirit of gathering requirements?

Currently, my documentation growing with Process Flow Diagrams, which are showing to be very effective in communicating requirements to J. My plan is to direct these diagrams as well to the actual users of the system to see if the proposed system will be correct in their perspective.

Yet perhaps with me being very green at the job and learning as I go along, it's important to ellicit deeply to find as much information and requirements as I can with the given amount of time. Are there best practices for interactions between BAs, one who is taking requirements, the other which is communicating requirements. Perhaps this is all too simple a concept, and I'm clearly missing out on something, but it could also be an issue that another BA has experienced. Do share your thoughts on this current issue I have as I trudge along to gather whatever I can on the issue.